The Problem

Each of Oanda's trading platforms—native iOS, native Android, web and desktop—had its own style, and was mananged by a different development team. This led to inconsistencies that made the experience feel disjointed.

On phones and tablets we supported both dark and light modes, but on desktop only light mode was available. This made harder for traders to switch seamlessly between platforms.

Lastly, designing across all these paltforms was also inefficient. Every new feature required four separate designs, followed by collaboration with each develpment team to implement them.

The Solution

The development teams were transitioning to a React Native tech stack. We took advantage of this and and built a modular, component-based design system, to match the development stack. We wanted consistency across platforms, while also making the development nore efficient.

Challenges

• Lack of time
• Company wide adoption
• Engaging developers
• Updating legacy styles

Making it work

• Embeded design system work into existing projects
• Collaborated with decision makers
• Worked closely with developers
• Audited, prioritized and standardized

The Process

Auditing our platforms

We audited our platforms, documenting inconsistencies. This was easiest —and perhaps, the most fun—part.

Setting up the Foundations

Getting started was one of our biggest hurdles. After reading articles and books, our small team of four designers came up with a plan of action.

• Each of us would take responsibility of a part
• We'll meet very frequently at the beginning to get the ball rolling
• We discuss every decision
• Keep detailed documentation
• Test thoroughly

Typography was one of the first big decisions—everyone had their favourite font. Our manager loved Avenir, but the licensing was too expensive. After lots of conversations, I suggested a practical and cost-effective solution: using each platform's native typeface. This meant San Francisco for Apple devices and Roboto for Android and web.

I used my knowledge of colour theory and my past experience —I had built a colour pallete generator for another product—to elevate our colour system. By adjusting Hue, Saturation, and Luminance (HSL), I developed color ramps that worked well across light and dark themes while staying consistent and accessible.

I went from this...

to this.

I gave them clear names, following conventions. This became the foundation of our semantic color system, allowing us to define colors by function—like actions, statuses, and components.

Collaborating on components

Once we were happy with our design system foundations, we started using them to build elements and components. We worked closely together with developers. Adding new components to our design system was an essential part of our overall design tasks. Before any new feature was considered complete we prototyped components in Framer, tested them internaly and with users, created documentation and collaborated with developers to implement them in Storybook.

Measuring success

Using and maintaining the design system became part of our daily routine. Communication with developers became easier, as now we had a common language. As our team grew from four to seven designers, everyone jumped in, using the system regularly and adding new components.

• The design system was used by four squads across two continents.
• It cut down development time. For example, we implemented a large feature on mobile and web with just one developer, which in the past it required three.
• Users noticed and appreciated the changes by increasing the number of positive reviews related to the interface.